This existed in the past in form of an edition field, similar to the field in Cargo.toml. However it was removed later because parsing an edition field from a flake.nix means that the Nix version you're using must be able to parse the entire file. This is not the case if e.g. a very old Nix is used to read a flake.nix using newer language features (or vice versa). See also NixOS/nix@e5ea01c.

This RFC has the exact same issue and doesn't mention this at all.

This RFC is now open for shepherd nominations.

This existed in the past in form of an edition field, similar to the field in Cargo.toml. However it was removed later because parsing an edition field from a flake.nix means that the Nix version you're using must be able to parse the entire file. This is not the case if e.g. a very old Nix is used to read a flake.nix using newer language features (or vice versa). See also NixOS/nix@e5ea01c.

This RFC has the exact same issue and doesn't mention this at all.

I think this breakage shouldn't be so unwanted as flakes are still not marked as stable. The disruption would be much smaller if something like this would actually be introduced sooner.

It's unstable for a reason I guess

And this compatibility system can be backported to old versions if that's the case.

I think this breakage shouldn't be so unwanted as flakes are still not marked as stable. The disruption would be much smaller if something like this would actually be introduced sooner.

This is not about a break to the current flake format (I agree that it's fine especially as long as flakes are unstable to change stuff), but about future language changes that may be used in flake.nix and as a result it's not possible for older Nix versions to parse the flake.nix (and the version field inside) to find out what language level is supposed to be used.

And this compatibility system can be backported to old versions if that's the case.

If the suggestion is about backporting new language features to older Nix versions to still be able to parse newer flake.nix files, then I'd like to hear from the Nix (and probably also Tvix) developers if they consider that feasible. I'm not too involved in either, but I highly doubt that this is sustainable and something time should be invested in.

What about storing the version in flake.lock? Presumably, flake.lock is less likely to need future Nix features. It can be included when the lock file is generated.

If there are still concerns about flake.lock compatibility with Nix versions, the version could be stored in a separate plaintext file, like .flake-version.

Additionally, being automatically added, the version could be fully automated. Instead of manually adding a version field, the version can be added based on the Nix version used to run the Flake file.

This RFC has not acquired enough shepherds. This typically shows lack of interest from the community. In order to progress a full shepherd team is required. Consider trying to raise interest by posting in Discourse, talking in Matrix or reaching out to people that you know.

If not enough shepherds can be found in the next month we will close this RFC until we can find enough interested participants. The PR can be reopened at any time if more shepherd nominations are made.

See more info on the Nix RFC process here

This RFC is being closed due to lack interest. If enough shepherds are found this issue can be reopened. If you don't have permission to reopen please open an issue for the NixOS RFC Steering Committee linking to this PR.